System and method using temporary identity for authentication with session initiation protocol

ABSTRACT

A communication method and a communication system providing services for subscribers having private identities is disclosed. The method includes receiving at a network element (S-CSCF) a communication from user equipment (UE) including a private identity of the subscriber and assigning a random string to the private identity.

CROSS REFERENCE TO RELATED APPLICATION

[0001] This application claims the benefit of the filing date ofProvisional Patent Application Serial No. 60/366,264, filed on Mar. 22,2002, entitled “Using Temporary IMPI (Private Identity) in IMS withSIP”, which application is incorporated herein by reference in itsentirety.

BACKGROUND OF THE INVENTION

[0002] 1. Field of the Invention

[0003] The invention relates to authentication and, more particularly,how authentication is performed in a communication network according tothe Internet Protocol Multimedia System (IMS) of the 3rd GenerationPartnership Project (3GPP).

[0004] 2. Description of the Prior Art

[0005]FIG. 1 shows the registration signalling flow for a user to becomeregistered. For the purpose of this registration signalling flow, thesubscriber UE is considered to be roaming. This flow also shows theauthentication of the private user identity. The signalling flow is from3GPP TS 24 228 V5.3.0 which is incorporated herein by reference in itsentirety. In this signalling flow, the home network does not have anactive network hiding configuration. The steps of registration aredescribed in a sequence following with the numbered paragraphs belowwhich correspond to the numbered steps of FIG. 1:

[0006] 1. GPRS Attach/PDP Context Establishment and proxy call statecontrol function (P-CSCF) Discovery (UE to GPRS)

[0007] This signalling flow is shown to indicate prerequisites for theregistration signalling.

[0008] 2. REGISTER request (UE to P-CSCF)

[0009] The purpose of this request is to register the user's SIP URIwith a serving call state control function (S-CSCF) in the home network.This request is routed to the P-CSCF because it is the only SIP serverknown to the UE. In the following SIP request, the Contact fieldcontains the user's host address.

[0010] The P-CSCF performs two actions, binding and forwarding. Thebinding is between the User's SIP address (user1_public1@home1.net) andthe host (terminal) address ([5555::aaa:bbb:ccc:ddd]) which was acquiredduring PDP context activation process. Request-URI: The Request-URI (theURI that follows the method name, “REGISTER”, in the first line)indicates the destination domain of this REGISTER request. The rules forrouting a SIP request describe how to use directory name service (DNS)to resolve this domain name (“registrar.home1.net“) into an address orentry point into the home operator's network (the I-CSCF). Thisinformation is stored in the USIM. Via: IPv6 address of the SIP sessionallocated during the PDP Context Activation process. From: Thisindicates the public user identity originating the REGISTER request. Thepublic user identity may be obtained from the USIM. To: This indicatesthe public user identity being registered. This is the identity by whichother parties know the subscriber. It may be obtained from the USIM.Contact: This indicates the point-of-presence for the subscriber - theIP address of the UE. This is the temporary point of contact for thesubscriber that is being registered. Subsequent requests destined forthis subscriber will be sent to this address. This information is storedin the P-CSCF and S-CSCF. Authorization: It carries authenticationinformation. The private user identity (user1_private@home1.net) iscarried in the user name field of the Digest AKA protocol. The URIparameter (directive) contains the same value as the Request-URI. Therealm parameter (directive) contains the network name where the usernameis authenticated. The Request-URI and the realm parameter (directive)value are obtained from the same field in the USIM and therefore, areidentical. Security-Client: lists the supported algorithm(s) by the UE.Supported: This header is included to indicate to the recipient that theUE supports the Path header.

[0011] Upon receiving this request the P-CSCF sets it's SIP registrationtimer for the UE to the Expires time in the request.

[0012] 3. DNS:DNS-Q

[0013] Based on the user's URI, the P-CSCF determines that UE isregistering from a visiting domain and performs the DNS queries tolocate the interrogating call state control function (I-CSCF) in thehome network. The look up in the DNS is based on the address specifiedin the Request URI.

[0014] The P-CSCF sends the REGISTER request—after local processing—tothe address indicated in the Request-URI. When forwarding the REGISTERrequest, the P-CSCF needs to specify the protocol, port number and IPaddress of the I-CSCF server in the home network to which to send theREGISTER request. The P-CSCF tries to find this information by queryingthe DNS. Since the Request-URI does not specify a numeric IP address,and the transport protocol and port number are not indicated, the P-CSCFperforms a naming authority pointer (NAPTR) query for the domainspecified in the Request-URI.

[0015] Once the IP address of the I-CSCF is obtained, the P-CSCFforwards the REGISTER request to this IP address (i.e.5555::aba:dab:aaa:daa) using the UDP protocol and port number 5060.

[0016] 4. REGISTER request (P-CSCF to I-CSCF)

[0017] The P-CSCF needs to be in the path for all mobile originated andmobile terminated requests for this user. To ensure this, the P-CSCFadds itself to the Path header value for future requests.

[0018] The P-CSCF binds the public user identity under registration tothe Contact header supplied by the user.

[0019] The P-CSCF adds also the P-Visited-Network-ID header with thecontents of the identifier of the P-CSCF network. This may be thevisited network domain name or any other identifier that identifies thevisited network at the home network.

[0020] This signalling flow shows the REGISTER request being forwardfrom the P-CSCF to the I-CSCF in the home domain. Path: This is theaddress of the P-CSCF and is included to inform the S- CSCF where toroute terminating sessions. Require: This header is included to ensurethat the recipient correctly handles the Path header. If the recipientdoes not support the path header, a response will be received with astatus code of 420 and an Unsupported header indicating “path”. Such aresponse indicates a misconfiguration of the routing tables and therequest has been routed outside the IM CN subsystem.P-Visited-Network-ID: It contains the identifier of the P-CSCF networkat the home network. P-Charging-Vector: The P-CSCF inserts this headerand populates the IMS Charging Id (ICID) parameters with a unique valueand the IP 4 address of the P-CSCF.

[0021] 5. Cx: User registration status query procedure

[0022] The I-CSCF makes a request for information related to theSubscriber registration status by sending the private user identity,public user identity and visited domain name to the HSS. The HSS returnsthe S-CSCF required capabilities and the I-CSCF uses this information toselect a suitable S-CSCF.

[0023] For detailed message flows see 3GPP TS 29.228.

[0024] 6. REGISTER request (I-CSCF to S-CSCF)

[0025] I-CSCF does not modify the Path header.

[0026] This signalling flow forwards the REGISTER request from theI-CSCF to the S-CSCF selected.

[0027] Path: The S-CSCF stores the contents of the Path header and usesthe URI for routing mobile terminated sessions.

[0028] Upon receiving this request the S-CSCF may set its SIPregistration timer for this UE to the Expires time in this request orthe S-CSCF may assign another registration timer for this registration.

[0029] 7. Cx: Authentication procedure

[0030] Since the REGISTER request arrived without integrity protectionto the P-CSCF, the S-CSCF shall challenge it. For this, the S-CSCFrequires at least one authentication vector to be used in the challengeto the user. If a valid authentication vector (AV) is not available,then the S-CSCF requests at least one AV from the HSS.

[0031] The S-CSCF indicates to the HSS that it has been assigned toserve this user.

[0032] For detailed message flows see 3GPP TS 29.228.

[0033] 8. Authentication vector selection

[0034] The S-CSCF selects an authentication vector for use in theauthentication challenge. For detailed description of the authenticationvector, see 3GPP TS 33.203.

[0035] The authentication vector may be of the form as in 3GPP TS 33.203(if IMS AKA is the selected authentication scheme):

[0036] AV=RAND_(n)∥AUTN_(n)∥XRES_(n)∥CK_(n)∥IK_(n) where:

[0037] RAND: random number used to generate the XRES, CK, IK, and partof the AUTN. It is also used to generate the RES at the UE.

[0038] AUTN: Authentication token (including MAC and SQN).

[0039] XRES: Expected (correct) result from the UE.

[0040] CK: Cipher key (optional).

[0041] IK: Integrity key.

[0042] 9. 401 Unauthorized response (S-CSCF to I-CSCF)

[0043] The authentication challenge is sent in the 401 Unauthorizedresponse towards the UE.

[0044] WWW-Authenticate: The S-CSCF challenges the user. The nonceincludes the quoted string, base64 encoded value of the concatenation ofthe AKA RAND, AKA AUTN and server specific data. The S-CSCF appends alsothe Integrity Key (IK) and the Cyphering key (CK).

[0045] The actual nonce value in the WWW-Authenticate header field isencoded in base64, and it may look like: nonce=“A34Cm+Fva37UYWpGNB34JP”.

[0046] 10. 401 Unauthorized response (I-CSCF to P-CSCF)

[0047] The authentication challenge is sent in the 401 Unauthorizedresponse towards the UE.

[0048] 11. 401 Unauthorized response (P-CSCF to UE)

[0049] The P-CSCF removes any keys received in the 401 Unauthorizedresponse and forwards the rest of the response to the UE.

[0050] WWW-Authenticate: The P-CSCF removes the IK and CK parameters(directives) from the header.

[0051] 12. Generation of response and session keys at UE

[0052] The UE calculates the response, RES, and also computes thesession keys IK and CK. The RES is put into the Authorization header andsent back to the registrar in the REGISTER request.

[0053] 13. REGISTER request (UE to P-CSCF)

[0054] Authorization: This carries the response to the authenticationchallenge received in step 11 along with the private user identity, therealm, the nonce, the URI and the algorithm.

[0055] This message is protected by the IPsec SA negotiated.

[0056] 14. DNS: DNS-Q

[0057] This is according to step 3.

[0058] 15. REGISTER request (P-CSCF to I-CSCF)

[0059] This signalling flow shows the REGISTER request being forwardedfrom the P-CSCF to the I-CSCF in the home domain.

[0060] Path: This is the P-CSCF URI and it is included to inform theS-CSCF where to route terminating sessions.

[0061] 16. Cx: User registration status query procedure

[0062] The I-CSCF requests information related to the Subscriberregistration status by sending the private user identity, public useridentity and visited domain name to the HSS. The HSS returns the S-CSCFname which was previously selected in step 5 (Cx: User registrationstatus query procedure).

[0063] For detailed message flows see 3GPP TS 29.228.

[0064] 17. REGISTER request (I-CSCF to S-CSCF)

[0065] This signalling flow forwards the REGISTER request from theI-CSCF to the S-CSCF.

[0066] Path: The S-CSCF stores the contents of the Path header and usesthis URI for routing mobile terminated sessions.

[0067] P-Charging-Vector: The S-CSCF stores the contents of the ICIDparameters for possible charging activities.

[0068] 18. Authentication

[0069] Upon receiving an integrity protected REGISTER request carryingthe authentication response, RES, the S-CSCF checks that the user'sactive, XRES matches the received RES. If the check is successful thenthe user has been authenticated and the public user identity isregistered in the S-CSCF.

[0070] 19. Cx: S-CSCF registration notification procedure

[0071] On registering a user the S-CSCF informs the HSS that the userhas been registered at this instance. Upon being requested by theS-CSCF, the HSS will also include the user profile in the response sentto the S-CSCF.

[0072] For detailed message flows see 3GPP TS 29.228.

[0073] 20. 200 OK response (S-CSCF to I-CSCF)

[0074] The S-CSCF sends a 200 (OK) response to the I-CSCF indicatingthat Registration was successful.

[0075] Service-Route: The S-CSCF inserts the Service-Route header valuethat includes the own S-CSCF URI.

[0076] 21. 200 OK response (I-CSCF to P-CSCF)

[0077] The I-CSCF forwards the 200 (OK) response from the S-CSCF to theP-CSCF indicating that Registration was successful.

[0078] 22. 200 OK response (P-CSCF to UE)

[0079] The P-CSCF saves the value of the Service-Route header andassociates it with the UE. The P-CSCF then forwards the 200 (OK)response from the I-CSCF to the UE indicating that Registration wassuccessful.

[0080] The 3GPP Technical Specification 24.229, which is incorporated byreference in its entirety, in Chapter 5.1.1.1A discusses that asubscriber has multiple IMS Public User Identities (IMPUs) and a singleIMS Private User Identity (IMPI). The IMPUs are either explicitlyregistered or implicitly registered using messages of the SessionInitiation protocol (SIP). As a result, the identity to be used formessage origin verification in the P-CSCF is still open.

[0081] In IMS the user is authenticated in the S-CSCF duringregistration as has been discussed above. The message originverification is delegated from the S-CSCF to the P-CSCF. Currently it isnot clear how the message origin verification can be done in the P-CSCF.The IMPI is not present in messages other than REGISTER requests andusing the IMPUs for this purpose is not appropriate.

[0082] One possibility is to include the IMPI into all of the messagesinitiated by the UE. However this solution is not safe as it exposes theuser's IMPI on the air interface.

[0083] Currently in 3GPP the implicitly registered IMPUs are transferredfrom the Home Subscriber Server (HSS) to the S-CSCF and from the S-CSCFto the P-CSCF. The P-CSCF then keeps the user's explicitly andimplicitly registered IMPUs together with the session keys IK and CK.Whenever a message arrives, the P-CSCF verifies the integrity protectionusing IK, then verifies if the identity included in the From: (or RPI)header field relates to that specific IK or not. The TechnicalSpecifications of 3GPP to date are incorporated herein by reference intheir entirety.

[0084] The current detailed description of the registration andauthentication procedure of the 3GPP Technical Specifications describedabove with reference to FIG. 1 relative to the present invention issummarized as follows:

[0085] When the UE sends a REGISTER request to the network, it includesthe IMPI in the Authorization header field (possibly base64 encoded).The P-CSCF receives the request and forwards the request (step 4) to theS-CSCF unmodified.

[0086] On receiving a REGISTER request from an unauthenticated user, theS-CSCF (step 8) requires at least one authentication vector (AV) to beused in the challenge to the user. If a valid AV is not available, thenthe S-CSCF requests at least one AV from the HSS.

[0087] The S-CSCF sends a 401 Unauthorized response to the UE (steps9-11) containing the RAND and AUTN parameters. This message alsoincludes the session keys IK and CK. The P-CSCF removes and stores theIK and CK keys before forwarding the response to the UE.

[0088] Upon receiving the response from the S-CSCF, the UE uses the RANDparameter to derive the IK and CK keys (step 12).

[0089] The UE sends a new REGISTER request (step 13) to the network,including its IMPI which integrity protects the message using IK. Uponreceiving the request, the P-CSCF verifies the integrity of the REGISTERrequest using IK and forwards (steps 15 and 17) the message to theS-CSCF only when the verification was successful. In addition, theP-CSCF needs to signal to the S-CSCF that this message was received withintegrity protection. After receiving the request, the S-CSCF performswhatever action is needed to register the subscriber and returns a 200OK response (steps 20-22) to the UE.

[0090] In IMS, the user is authenticated in the S-CSCF duringregistration. The message origin verification is delegated from theS-CSCF to the P-CSCF. Currently it is not clear how the message originverification can be done in P-CSCF. The IMPI (IMS Private Identity) isnot present in messages other than REGISTER requests and using the IMPUs(IMS Public Identity) for this purpose is not appropriate.

SUMMARY OF THE INVENTION

[0091] The invention is a system and method which produces a temporaryIMPI (hereinafter TIMPI) used in IMS for message origin verification.The invention further includes the use of the TIMPI for message originverification in IMS with the SIP protocol.

[0092] A communication method in a network providing services forsubscribers having private identities in accordance with the inventionincludes receiving at a network element a communication from userequipment including a private identity of the subscriber; and assigninga random string to the private identity. The random string may bedelivered to the user equipment. The random string may be used formessage origin verification in a forthcoming communication from the userequipment. The communication from the user equipment may be integrityprotected. The communication from the user equipment may be a SIPRegister request. The random string may be delivered to the userequipment by using an acknowledgement message. The acknowledgementmessage may be a SIP 200 OK message. The network element may be aserving network element to which the subscriber registers for services.The serving network element may be a S-CSCF. The random string may besaved in a proxy network element disposed between the user equipment anda serving network element. The proxy network element may be a P-CSCF.The message origin verification may take place in the proxy networkelement.

[0093] A communication system providing services for subscribers havingprivate identities in accordance with the invention includes a userequipment; and a network element; and wherein the network elementreceives a communication from the user equipment and the network elementassigns a random string to the private identity. The communicationsystem may deliver the random string to the user equipment. Thecommunication system may use the random string to perform verificationof a forthcoming communication from the user equipment. Thecommunication from the user equipment may be integrity protected. Thecommunication from the user equipment may be a SIP Register request. Thecommunication system may deliver the random string to the user equipmentas part of an acknowledgement message. The acknowledgement message maybe a SIP OK message. The network element may be a serving networkelement to which the subscriber registers for services. The servingnetwork element may be a S-CSCF. A proxy network element may be disposedbetween the user equipment and a serving network element which saves therandom string. The serving network element may be a S-CSCF and the proxynetwork element may be a P-CSCF. Message origin verification may takeplace in the proxy network element.

BRIEF DESCRIPTION OF THE DRAWING

[0094]FIG. 1 illustrates the prior art registration signalling for a SIPuser registration.

[0095]FIG. 2 illustrates user registration for IMS in accordance withthe present invention.

[0096] Like parts throughout the drawings are identified in the samemanner.

DESCRIPTION OF THE PREFERRED EMBODIMENT

[0097] The invention uses a TIMPI for the message origin verification inIMS with the SIP protocol. Using a TIMPI solves many of the problems ofthe prior art. The use of a TIMPI in accordance with the invention ispreferably used within IMS in association with the SIP protocol but isnot limited thereto.

[0098] The registration and authentication procedure of the invention isas follows with reference to FIG. 2 which is identical with the priorart through steps 1-19 described above with reference to FIG. 1. Steps1-19 are not described in detail hereinafter. When the S-CSCF at step 17receives an integrity protected REGISTER request from the UE, whichcontains the user's IMPI, the S-CSCF generates a random string. Thisrandom string is associated with the user's IMPI to form the TIMPI andis returned to the UE in the 200 OK response to the REGISTER request assteps 20-22. The P-CSCF needs to snoop the 200 OK response and saves therandom string with the TIMPI together with the IK and CK session keys ofthe user. The random string plays the role of a TIMPI. The 200 OKresponse to the REGISTER request carrying the TIMPI is integrityprotected and as such it is not possible to be modified by an intruderover the air interface. This is the reason for inserting TIMPI in the200 OK message rather than in a 401 Unauthorized Response.

[0099] For optimization purposes, the S-CSCF should not generate therandom identifier right after receiving an unprotected REGISTER request.If it does so, a hole is opened for Denial of Service (DoS) attacks, asan integrity protected REGISTER request may not follow a 401Unauthorized Response.

[0100] The TIMPI is inserted by the UE in all of the messages (step 23)sent towards the P-CSCF which may without limitation be in theauthorization header field. The P-CSCF performs message originverification by simply checking if the IK and the temporary TIMPI areassociated. The P-CSCF does not need to know about the possibleimplicitly registered IMPUs of the subscriber.

[0101] When a REGISTER request (step 23) is sent by a UE, having a validTIMPI, to the network, it contains TIMPI and is integrity protected.Upon receiving the request (step 25), the S-CSCF does a verificationrather than a new authentication. Since the TIMPI is associated with theuser's IMPI, the S-CSCF can safely update the registration time of theuser to the requested one. The S-CSCF may provide a new TIMPI and returnthe new TIMPI to the user, or the S-CSCF may return the previous TIMPIto the user as part of an OK message as illustrated with steps 26-28,meaning that the old TIMPI is still valid.

[0102] The table below lists possible cases of how a REGISTER request issent by UE. The P-CSCF action, upon the REGISTER request (step 23), isspecified below: Integrity protected No integrity protection IMPIincluded Allowed Allowed Not recommended P-CSCF has to signal to S-CSCFthe no protection TIMPI desired Not allowed included Message shall besilently discarded

[0103] When the S-CSCF receives an integrity protected REGISTER request(step 25) from the UE, which contains the user's TIMPI, the S-CSCFgenerates the random string. The random string of the user's TIMPI isassociated with the user's IMPI and is returned to the user or a newTIMPI is generated by the S-CSCF and returned in the 200 OK response tothe REGISTER request (steps 26-28). The P-CSCF examines the 200 OKresponse and saves the random string together with the IK and CK sessionkeys of the user. The random string plays the role of a temporary IMPI.The 200 OK response to the REGISTER request carrying the TIMPI (steps26-28) is integrity protected and as such it is not possible to bemodified by an intruder over the air interface. This is the reason forinserting the TIMPI in the 200 OK message rather than 401 Unauthorizedresponse message).

[0104] While the invention has been described in terms of its preferredembodiment, it should be understood that numerous modifications may bemade thereto without departing from the spirit and scope of the presentinvention. It is intended that those modifications fall within the scopeof the appended claims.

1. A communication method in a network providing services forsubscribers having private identities comprising the steps of: a)receiving at a network element a communication from user equipmentincluding a private identity of the subscriber; and b) assigning arandom string to the private identity.
 2. A method according to claim 1comprising a step of: delivering the random string to the userequipment.
 3. A method according to claim 1 comprising a step of: usingthe random string for message origin verification in a forthcomingcommunication from the user equipment.
 4. A method according to claim 2comprising a step of: using the random string for message originverification in a forthcoming communication from the user equipment. 5.A method according to claim 1 wherein: the communication from the userequipment is integrity protected.
 6. A method according to claim 2wherein: the communication from the user equipment is integrityprotected.
 7. A method according to claim 3 wherein: the communicationfrom the user equipment is integrity protected.
 8. A method according toclaim 4 wherein: the communication from the user equipment is integrityprotected.
 9. A method according to claim 1 wherein: the communicationfrom the user equipment is a SIP Register request.
 10. A methodaccording to claim 2 wherein: the communication from the user equipmentis a SIP Register request.
 11. A method according to claim 3 wherein:the communication from the user equipment is a SIP Register request. 12.A method according to claim 4 wherein: the communication from the userequipment is a SIP Register request.
 13. A method according to claim 2wherein: delivering the random string to the user equipment uses aacknowledgement message.
 14. A method according to claim 4 wherein:delivering the random string to the user equipment uses aacknowledgement message.
 15. A method according to claim 6 wherein:delivering the random string to the user equipment uses aacknowledgement message.
 16. A method according to claim 8 wherein:delivering the random string to the user equipment uses aacknowledgement message.
 17. A method according to claim 10 wherein:delivering the random string to the user equipment uses aacknowledgement message.
 18. A method according to claim 13 wherein: theacknowledgement message is a SIP 200 OK message.
 19. A method accordingto claims 1 wherein: the network element is a serving network element towhich the subscriber registers for services.
 20. A method according toclaim 19 wherein: the serving network element is a S-CSCF.
 21. A methodaccording to claim 1 comprising: saving the random string in a proxynetwork element disposed between the user equipment and a servingnetwork element.
 22. A method according to claim 21 wherein: the servingnetwork element is a S-CSCF and the proxy network element is a P-CSCF.23. A method according to claim 21 wherein: message origin verificationtakes place in the proxy network element.
 24. A method according toclaim 23 wherein; the proxy network element is a P-CSCF.
 25. Acommunication system providing services for subscribers having privateidentifies comprising: a user equipment; and a network element; andwherein the network element receives a communication from the userequipment and the network element assigns a random string to the privateidentity.
 26. A communication system according to claim 25 wherein: thecommunication system delivers the random string to the user equipment.27. A communication system according to claim 25 wherein: thecommunication system uses the random string to perform verification of aforthcoming communication from the user equipment.
 28. A communicationsystem according to claim 26 wherein: the communication system uses therandom string to perform verification of a forthcoming communicationfrom the user equipment.
 29. A communication system in accordance withclaim 25 wherein: the communication from the user equipment is integrityprotected.
 30. A communication system in accordance with claim 26wherein: the communication from the user equipment is integrityprotected.
 31. A communication system in accordance with claim 27wherein: the communication from the user equipment is integrityprotected.
 32. A communication system in accordance with claim 28wherein: the communication from the user equipment is integrityprotected.
 33. A communication system according to claim 25 wherein: thecommunication from the user equipment is a SIP Register request.
 34. Acommunication system according to claim 26 wherein: the communicationfrom the user equipment is a SIP Register request.
 35. A communicationsystem according to claim 27 wherein: the communication from the userequipment is a SIP Register request.
 36. A communication systemaccording to claim 28 wherein: the communication from the user equipmentis a SIP Register request.
 37. A system according to claim 26 wherein:the communication system delivers the random string to the userequipment as part of an acknowledgement message.
 38. A system accordingto claim 28 wherein: the communication system delivers the random stringto the user equipment as part of an acknowledgement message.
 39. Asystem according to claim 30 wherein: the communication system deliversthe random string to the user equipment as part of an acknowledgementmessage.
 40. A system according to claim 32 wherein: the communicationsystem delivers the random string to the user equipment as part of anacknowledgement message.
 41. A communication system according to claim37 wherein: the acknowledgement message is a SIP OK message.
 42. Acommunication system according to claim 25 wherein: the network elementis a serving network element to which the subscriber registers forservices.
 43. A communication system according to claim 42 wherein: theserving network element is a S-CSCF.
 44. A communication systemaccording to claim 25 comprising: a proxy network element disposedbetween the user equipment and a serving network element which saves therandom string.
 45. A communication system according to claim 44 wherein:the serving network element is a S-CSCF and the proxy network element isa P-CSCF.
 46. A communication system according to claim 44 wherein:message origin verification takes place in the proxy network element.